New BIP: Ordinal Numbers #1408
New BIP: Ordinal Numbers #1408
Conversation
|
@luke-jr I think this qualifies for a BIP assignment. Edit: I spoke in haste. Will return with feedback. |
| The ordinal numbers of sats in transaction inputs are transferred to output | ||
| sats in first-in-first-out order, according to the size and order of the | ||
| transactions inputs and outputs. |
There was a problem hiding this comment.
I like ordinals and inscriptions. However, the concept of assigning serial numbers to sats or transferring them based on size and order isnt a part of bitcoin protocol. So ordinals do not really require a BIP and could work at layer 2 or externally.
Note: This repo is considered an official bitcoin repo for improvements. However, you can always maintain such docs outside this repo and could be used by other bitcoin projects if necessary.
There was a problem hiding this comment.
BIPs are not just about layer 1 protocols. As an example, BIPs 173/350 (bech32 and bech32m) define an address format that never touches the p2p layer at all. BIP32 describes a key derivation scheme that is not even visible on the blockchain or p2p layer.
Essentially, to get a BIP, you just need to post something on the mailing list and then post a well-formatted well-specified document here. It doesn't need to be something that anybody needs to use, or even something that anybody should use. I guess it needs to be sorta Bitcoin-related, but this meets that threshold :).
There was a problem hiding this comment.
Agreed. This doc could be maintained outside the BIPs repo but if the author wants a BIP I don't see a reason to prevent this.
From BIP 2:
Reasons for rejecting BIPs include duplication of effort, disregard for formatting rules, being too unfocused or too broad, being technically unsound, not providing proper motivation or addressing backwards compatibility, or not in keeping with the Bitcoin philosophy. For a BIP to be accepted it must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement. The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly.
The "must represent a net improvement" is a bit of a grey area but when unsure I think the BIP editors should lean towards giving the BIP number. If people want to use ordinals a specification on how to use ordinals (ideally using block space as efficiently as possible) seems like a net improvement to me.
|
NACK. Outside of the scope of Bitcoin Improvement Proposals. I suggest you start a new Ord Improvement Proposal repository for standards relating to your software/system, if not done already. |
|
Seems within scope to me, even if ultimately rejected by the community. Edit: Though since this is essentially an attack on Bitcoin, I would encourage the author to withdraw it and abandon it entirely. |
|
Thank you Luke, I appreciate it. Users have already begun financially relying on the details of ordinals, so I think at least for clarity it should be a BIP. A number like 1337 or 4000 might be good. It's fun, and also suggests that it's way off in the stratosphere, away from the other, more serious BIPs. Also, having a larger number than the 300 series might signal nicely to those concerned that it's a worse idea than Drivechain. |
|
I'm very open to style, license, and scope feedback, since I've never submitted a BIP here for review. |
Nice, fixed! Thank you 👍 |
bip-0000.mediawiki
Outdated
| Status: Draft | ||
| Type: Informational | ||
| Created: 2022-02-02 | ||
| License: PD |
There was a problem hiding this comment.
Why is Public Domain no longer acceptable for new BIPs?
- In some jurisdictions, public domain is not recognised as a legitimate legal action, leaving the BIP simply copyrighted with no redistribution or modification allowed at all.
(BIP-0002)
bip-0000.mediawiki
Outdated
| for output in block.transaction[0].outputs: | ||
| output.ordinals = coinbase_ordinals[:output.value] | ||
| del coinbase_ordinals[:output.value] | ||
| </pre> |
bip-0000.mediawiki
Outdated
| @@ -69,7 +69,7 @@ mined, not how many actually were. | |||
|
|
|||
| Sats are numbered and transferred with the following algorithm: | |||
|
|
|||
| <pre> | |||
| ```python | |||
There was a problem hiding this comment.
| ```python | |
| <source lang="python"> |
|
I don't think this should be a BIP, but rather it should be managed separately like BOLTs for lightning, EIPs for Ethereum, and SLIPs for Satoshi Labs proposals. NACK. |
|
Is this going to need a series of BIPs or is a single BIP number going to be sufficient @casey?
@junderw: It has been discussed previously by at least one BIP editor that BOLTs could potentially become BIPs in future. So BOLTs aren't in same bracket as Ethereum EIPs which are for a totally different blockchain. I'm not sure about the history on SLIPs. It seems to me that some of those could have possibly been BIPs too and perhaps could be in future. I get why people don't like this proposal but there are other BIPs that are disliked too and we should try to be consistent with the guidelines from BIP 2 of what should and shouldn't be a BIP even if we dislike a particular proposal. |
BOLTs should stay separate. It has grown into something that would ideally have its own proposals.
|
|
Ugh, looked into some of the cheerleaders for this and it is the Ethereum, anti Bitcoin maximalists, "we need to change Bitcoin culture" time wasting trolls. edit: Think this is going to be a time wasting attack vector for the BIP editors so leaning towards not giving it this a BIP number now. |
Spreading misinformation that coinjoin transactions are affected because of ordinals is an attack on bitcoin. Doesn't look good for a BIP editor to get involved in such things. Maybe read this thread when you get time: https://web.archive.org/web/20230215002302/https://twitter.com/1440000bytes/status/1624540320309596160 |
This is hugely irrelevant to this PR discussion. |
| [https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki BIP-34] made | ||
| the creation of transactions with duplicate IDs impossible. | ||
|
|
||
| For the purposes of the assignment algorithm, the coinbase transaction is |
There was a problem hiding this comment.
This paragraph and next could use more clarification. If the input order is coinbase subsidy + inputs of fee-paying transactions, what is the result when a miner forgoes either the subsidy and/or fees? Which ordinals are "burned" those from the subsidy, or those from the fees paid? E.g., at time of writing, subsidy is 625,000,000 sats. If fees paid are another 10,000,000 and the miner erroneously accepts 322,500,000 does that burn effectively burn the ordinals of all the fees paid and part of the subsidy that should have been ?
This is relevant to PR discussion as BIP editor who is expected to merge this pull request has accused author of attacking bitcoin and involved in sharing misleading things on social media related to this PR. Let me share something that is irrelevant to this PR: #1408 (comment) It doesn't matter who uses bitcoin and it can be used for things you don't like or by people you don't like. |
Anyone may have opinions and share their thoughts. This does not impact the merging of this BIP
It's not something a subset of people "don't like" -- it is misuse of the network, which was meant for financial transactions (the whitepaper, name and code point to this) for data storage (which was not an intended use case, and any ways to do that were limited, like OP_RETURN being capped at 80 bytes) |
|
I'd like to just comment here with my understanding of the BIP process, since there seem to be many misunderstandings. An accepted BIP does not indicate endorsement by the BIP repo maintainers, Bitcoin Core, or the larger Bitcoin community. A BIP is more akin to a form of technical documentation or standard. Similarly, a BIP number is also not an endorsement, merely an identifier which allows the Bitcoin community to more easily reference and discuss the BIP in question. A lot of the comments here are off topic, according to my understanding of this repo's purpose. If my understanding is wrong, please let me know, and I'll close this PR! |
Also, what happens if merging of this gets delayed? It doesn't prevent you from using ordinals or inscribing what is in my opinion bullshit. |
|
NACK. This BIP is antithetical to the goals of Bitcoin, an open financial network. Eliminating fungibility and enabling new types of tracking across transactions is not a feature, but a bug to be fixed. |
Standards relating to tokenization schemes and NFTs are completely irrelevant to Bitcoin. As mentionned in my previous comment, if Ord wants to standardize its codebase and practices, they should create their own Ordinals Improvement Proposals. |
@Semisol It was not actually limited in practice, since customers of miners' blockspace have been storing arbitrary data in Bitcoin via p2ms regardless, due to the lack of OP_RETURN flexibility, which was worse for Bitcoin than OP_RETURN (occupied nodes' RAM), yet done anyway because "you cannot stop the free market"; if you try, you will end up with sub-optimal outcomes and an inefficient market. Inscriptions is better than the real alternative of p2ms, and so is an improvement even in just this simple way to Bitcoin's functioning. Arbitrary data (with its inherent mix of pros and cons) has been stored in Bitcoin throughout its history, prior to Inscriptions, so Inscriptions is really nothing new:
@Semisol However, it is exactly about what people do not like, and it is exactly not a misuse of the network. In reality, the market demand (fee market is competitive, fee rate determines priority; if the non-financial tx with higher fee rate outcompetes the financial tx with lower fee rate, then this is the free market speaking about where real economic value lies, as an example) is what actually determines for which use the miners sell their finite blockspace to their customers (those paying for transactions) -- and is what determines good/desirable vs. bad/undesirable/spam/nonsense/stupid/etc. The individual opinion of someone is not what determines which uses are valid or invalid, as of course it is the miners who "own" that blockspace, so it is only the miners who make that determination (and if users for example try to stop nodes from relaying certain transactions to miners, ahem, it only incentivizes miners to create alternative channels for users to directly send transactions to miners, which as you may imagine creates all kinds of unintended consequences that are bad for Bitcoin -- you must remember the bottom line realities of the network, upon which the unstoppable free market operates, in order to avoid making mistakes that make what is seen as a problem become even worse). Miners are incentivized to increase their total revenue per block, as a course of normal business, and also as they try to offset their exponentially-declining subsidy revenue (which is meant to be replaced with fee revenue, hence the name 'subsidy'). As such, miners do not care to pass moral or any other such judgement to choose to censor technically-valid bitcoin transactions (and since Bitcoin is supposed to be a censorship-resistant network, we would hope so!). At best, Bitcoin is designed so that miners simply behave as rational economic actors, which means they should be optimizing their fee revenue, which in turn is good for Bitcoin as it encourages censorship-resistance, and also increases Bitcoin's "security budget" (relevant when considering Bitcoin inherently exists in an adversarial environment in which hostile hashrate must be assumed to exist) -- by encouraging higher-fee transactions that are economically meaningful on the base layer (this is what determines 'value', not any moral or other judgment). Anything that increases demand for Bitcoin's supply of blockspace, thus allowing bocks to be filled with a floor of lower fee-rate transactions to create a competitive fee-rate market, acts to boost fee-rate pressure, thus helping to increase the fee-to-subsidy ratio of each block and improving Bitcoin's security. Since security is the number 1 priority of any Bitcoin user, without which everything else is irrelevant, the number 1 priority should be to boost demand for blockspace. Inscriptions simply popularizes another demand for blockspace (arbitrary data stored by customers desiring the best decentralized network on Earth), beyond the existing demands from SoV (store of value) and MoE (medium of exchange) (low-value high-volume MoE transactions go on second layers, high-value low-volume MoE transactions go on base layer) uses that so far have not been sufficient to reliably fill blocks & generate enough fee pressure to offset the subsidy (fee-to-subsidy ratio of 100%). Inscriptions theoretically (and so far in practice, however the fee-to-subsidy ratio of each blocks is still only 3.5%, since this only picked up steam 2 weeks ago) achieves this boost in blockspace demand by filling blocks and increasing economic activity on the base layer (vs. the last 1.5 years that have been marred with many non-full blocks and thus paltry fees -- objectively bad from the point of view of network security), thus objectively it is not a misuse of the network, and rather it is "good for bitcoin" for anyone who cares about Bitcoin's security and security sustainability (vis a vis the hashrate sustaining itself without the exponentially-declining subsidy), and who is able and willing to truly appreciate what a censorship-resistant network requires to function successfully in an adversarial environment. Really, it is a matter of being focused on priorities, so that the number 1 priority of security and security sustainability is able to rise in your mind to the top of consideration (over lesser considerations of judging uses as 'good' vs. 'bad'/'nonsense'/'spam'). Disclaimer: I have not used Inscriptions nor do I intend to use it anytime soon, so I am not speaking in my own interest, I am only speaking in the interest of Bitcoin. |
@vikbtc From my understanding, this is actually FUD. The Ordinals system is voluntary, and it is a way of designating sats as having different numismatic value, based on fixed properties, so simplistically:
This classification doesn’t make sats less fungible, since it’s only judging based on “rarity”, with the idea to add numismatic market value on top of the underlying bitcoin market value of the sats. It does not make sense to not accept sats on basis of rarity labeling, so it doesn’t hurt fungibility. It’s like fiat coins, which can all be judged numismatically on such a scale of “rarest” to “unrarest”. This aspect does not hurt fungibility of the coins, and it only potentially helps you with more value for the coins if you recognize the numismatic value of the coins. So, Ordinals (system of having sats of different rarities) does not hurt you, only potentially helps you. Note: Ordinals and Inscriptions are two different things. I have commented about Inscriptions in my previous post. |
|
Concept ACK for BIP assignment. |
Thanks to make it clear. We need to do some kind of literature review of "scope" related of this repository. The point is whether this initiative is in-scope or out-of-scope of the repository . |
|
BIP 39, which is not implemented in core, is tagged as Standards Track, 32 is tagged as Informational. It seems to me that this is simply an editorial field in it's current form as it lacks sufficiently strict rules to adequately catagorize all relevant proposals. As such, it seems unreasonable that we are now using flaws in the clarity of BIP 2 to continue withholding a BIP number for what is literally just an informational BIP. |
Where can I find some definition of scope or maybe a BIP of "definition of scope " is also need 😀😀 |
BIP39 is discouraged for use despite being widely used and is an example of why we need to be more careful with merging BIPs. "We made horrible mistakes before so lets make another similarly horrible mistake now" is not the proper logic to run with here. |
The opposite will be additude : |
|
I am not a big fan of BIP39, but let's remember that it was merged in 2013. It was years before the problems with it became apparent and probably many of them required widespread usage to notice. (Today many of them would be readily apparent, but we have a lot more experience now.) If its issues were readily apparent at the time I would expect its many implementors to have requested changes. So there isn't a clear lesson to be taken from that IMHO. |
Making the criteria for what is in-scope for a BIP less ambiguous would definitely be an improvement over the current situation. However, I believe that ordinals would be in-scope for a BIP given any reasonable criteria. As mentioned in the ordinals BIP, ordinals can be used as public identifiers that can receive bitcoin payments, where the underlying private keys can be swapped, to allow for private key rotation in case of compromise or a change in the underlying custody setup. Alice tells Bob the ordinal number of a sat that she controls, and Bob can send bitcoin to the address holding that sat. Alice can then transfer that sat to a new address, indicating that going forward, she wishes to be paid at that new address. Alice can swap address types, private keys, or any other aspect of her custody setup and need communicate no new information to Bob to continue receiving payments from him. This makes ordinals squarely in-scope for a BIP, given the vast number of other BIPS concerning addresses, wallets, and payment methods, which would surely not be made out-of-scope for a BIP under any reasonable criteria. The fact that it has other applications, like collectable sats and inscriptions, is not a tenable rationale for making ordinals itself out-of-scope for a BIP. |
"If a law can be falsified but has never been falsified, then we consider it to be valid." In the past long time discussion of this topic,there is no evidence that Ordinals theory is out-of-scope of the BIP range. I may suggest that editors should review all the discussion in the past long period and find if there is any solid evidence/fact that ordinals theory is NOT in-scope of the BIP range.If NOT, then I think editors should consider assuming Ordinals are in-scope of the BIP range for not finding any out-of-scope evidence . |
|
Ordinal theory, as a theory of satoshi numbering, is a very appropriate result to be proposed as a BIP for discussion. I hope that eventually ordinal theory can be accepted by the BTC main network. |
|
Where the ordinal theory needs fine-tuning:
I suggest that ordinal theory be adjusted to the following rules:
Among them, 2 and 5 have some differences from the current ordinal theory. |
|
Do @casey needs to have sexual intercourse with a BIP repository maintainer (or financially bribe one) for this draft to get a number ? …I’m only half-joking…There are already “Applications” BIP like BIP175, BIP197 or BIP199 which are only useful if both end-to-end wallet clients support them and there are not sustained hints those application-level protocol get today more fee traffic than ordinals, even less I doubt they have been sufficiently reviewed for the protocol to work as described. |
Please don't troll. Moreover, the suggestion that sex or bribes might be involved with a number assignment probably doesn't increase the motivation to do. |
|
@casey thoughts on #1408 (comment)? |
It’s only a half troll... I remember taking luke-jr defense in 2021 when a lot of people were talking about doing a bypass of its janitorial role as a bip maintainer and that time asking publicly the github organization admins to appoint without consensus new maintainers to have a bip number assigned to the BIP proposal they favored. I also think all the set of bips that were proposing increases of the block size (100, 101, 102, 103), whatever their level of technical seriousness where assigned a BIP, and all of them had more serious implications on the long-term technical and economical stability of the bitcoin peer-to-peer network, that this simple BIP had. There are sound conversations to add on the long-term effects of colored coins protocol on the Bitcoin ecosystem, though in a world of pay-to-contract and vanity addresses, ordinals are on a par with as an idea. So for an external observer, it’s unclear why the BIP is not assigned a number, after all it’s probable that all BIP maintainers have sharing communication channel to coordinate the assignment of number, otherwise it’s unclear how they avoid potential collisions in assignment due to working in an asynchronous digital work environment. |
|
I don’t think that comment is technically sound. About (1) at the consensus-level, there is no sat destruction unless the private keys is definitively loss (and it’s hard to prove a private key loss if there has been a boat accident) and about (2) one can make the same argument about lightning milli-sats, which have no meaning at the consensus-level, yet are interpreted by lightning nodes since 2018. The keys backing a block reward claim can have been shuffled in a discreet fashion by using shamir secret sharing, or other crypto-systems not letting obvious mark on the blockchain. |
This comment is suggesting a change to the way that numbering handles cases in which sats can be destroyed. The main change, point 2, would be that when a miner underpays the block reward, causing new sats to be destroyed, this be reflected in the numbering of sats in subsequent blocks. This would require that, in order to know when a sat with a particular number was created, you look back at all previous blocks to see if any had been destroyed, and so would greatly complicate implementations, and turn what previously were O(1) calculations into The author writes that point 5 is also a change, but I'm not sure what they mean by it. In any case, ordinals is already widely deployed as is, so this BIP seeks to document it in its existing state. |
|
I don't agree with @casey 's statement. Ordinals have been widely recognized, but they are more used to inscribe and index data. Most people don't care whether a satoshi's current ordinal number is n or m. Those who care are more familiar with technical details and pay more attention to the security of BTC and the indestructible nature of satoshis themselves. Satoshis can be lost, but the introduction of a BIP should not lead to the destruction of existing satoshis. This is unacceptable both technically and emotionally. Moreover, the Ordinals protocol also claims that Satoshi is indestructible, so why not unify the theory and implementation? Is there any reason to leave a gap that could destroy a Satoshi? |
|
In addition, computationally, there are countless ways to make indexing a satoshi O(1). We have implemented a go-code version of the indexer, where the satoshis are naturally sorted by birth order, with no gaps, and increment from 0. If needed, we can provide the source code for this indexer. The indexer data can be browsed through this webpage. Open this webpage, click NFT, and you can see all NFTs minted through Ordinals protocol: https://app.sat20.org/#/explorer |
Ordinal numbers are serial numbers for sats, assigned when mined and preserved across transactions.
I originally posted an earlier draft of the BIP to bitcoin-dev in February of last year.
We've implemented a wallet and block explorer, with public instances on mainnet, signet, and testnet, and a wallet that uses sat control to ensure specific sats are transferred to specific outputs. Constructing such transactions is tricky, especially given the dust limit and doing proper fee estimation, but once you get the details right it works well, and the fact that such transactions are otherwise normal Bitcoin transactions means that existing bitcoin infrastructure can be leveraged.
Since we've been using ordinal numbers in production and getting some users of the software it seemed appropriate to request a BIP number.
I've never applied for a BIP number before, so definitely let me know if anything should be changed or can be improved!